Security Expert Plus
Everything the console knows comes from Schneider Electric EcoStruxure Security Expert, and everything the console does goes back into Security Expert under the signed-in operator's own name.
View the deck → · Download the PDF →Security Expert Plus (SX+) is Knight Watch's operations platform layered on Schneider Electric EcoStruxure Security Expert. It gives the people who actually work a gate — guards, dispatchers, security supervisors — a console built for that job, without taking Security Expert out of the decision. Its operator console module is called the operator console.
If your organization already runs Security Expert, Security Expert Plus is an operations layer on top of it. It is not a replacement access-control system, and it is not a second permission model to keep in sync.
Read the six-board deck · Download the PDF
Security Expert still decides
Security Expert Plus enforces Security Expert's own permission model rather than replacing it.
The console reads the Schneider Electric EcoStruxure Security Expert database directly for read-only reference data — including each operator's Role, Preset, Security Levels and Record Groups — and turns that vendor-held configuration into the session's claims, so Security Expert remains the authority on what an operator is allowed to do.
What is rebuilt is the enforcement point, not the model. A server-side claims middleware checks the required table and command claim on every authenticated API endpoint and returns 403 when it is not met. Every live control command — door release, output activation — still goes through the Security Expert SOAP service, which applies its own authorization. Security Expert Plus never bypasses it.
Databases are kept separate and deliberately not consolidated, each with a single owner and a clear write boundary. Vendor databases stay vendor-owned: the application never writes or migrates them.
A command carries the name of the person who issued it
A door command reaches Schneider Electric Security Expert under the signed-in operator's own SE operator session — their operator record's identity and credential, not a shared service account — so Security Expert's own event log names the person who opened the door.
If an operator holds no live SE session, the server re-establishes their session and retries first. If there is still no session, the command is refused rather than re-routed through the service account.
That last sentence is the design. A refusal is recoverable. A door that opened under the wrong name is not.
The operator console
the operator console is built as a set of tabs whose visibility follows the operator's access claims, enforced server-side rather than in the browser. Administrative tabs stay visible but greyed out for operators without the admin claim, so the console looks the same to everyone and no one is left guessing what exists; tabs whose data the operator has no claim to at all are hidden entirely. The same claim check runs on every endpoint behind those tabs — the greyed tab is not the security control, the endpoint is.
Nine tabs in the build as of 31 August 2026 — Cardholder Lookup, Turnstile Bank Management, Door / Device Management, Custom Attributes, Gate Logging, Recent Activity, Controller Health, Config and Repair Queue — of which four are greyed out for non-admins and one (Controller Health) is hidden without its own claim.
Three things an operator does constantly:
- Cardholder lookup. Only the records the operator's record groups actually grant, with the cardholder photo served from its own database rather than copied into the console's.
- Door release, with a reason. Every door release that bypasses an access-level or state rule requires an explicit human acknowledgement with a written reason, and that reason is recorded against the access-control event in a dedicated release-audit table.
- Live door state. Door chips update live: a lock, unlock, or latch shows immediately whether it came from an operator command, the vendor's own client, a card or keypad swipe, or a scheduled action.
The HR read path reads a live HR view through a circuit breaker that falls back to a locally cached copy and re-probes the view after a cooldown, so an HR-feed outage degrades data freshness rather than taking the operator console down. It is a read path only — the platform never writes back to HR data. Implemented and unit-tested, merged to a customer engagement's release branch on 19 August 2026; not on the platform mainline and not in a released build.
Who is allowed to do what
An identity that is not already a provisioned Security Expert operator does not get in, by either sign-in route.
Single sign-on. the operator console includes a PingFederate (Ping Identity) OpenID Connect sign-in path — Authorization Code with PKCE — that resolves the federated identity to an existing Security Expert operator. Identity matching runs sub → preferred_username → email.
Fails closed on no match. A user who authenticates successfully at the identity provider but has not been provisioned as a Security Expert operator is denied access, and the SSO sign-in flow never creates an operator account. Operators are created only by an administrator holding full access to the Operators table.
The unset-role gate. the operator console refuses a session to any operator whose role in Schneider Electric Security Expert is left unset. An unprovisioned account is denied at sign-in rather than admitted with an empty permission set — and where single sign-on is deployed, the same gate is applied at identity resolution, so an operator refused one sign-in route cannot enter by the other.
Record-group scoping is preserved, not discarded. the operator console enforces Security Expert's native record-group scoping at the query layer: a plant-scoped operator sees only the doors and records their role's record groups actually grant. Verified end-to-end against a live production estate on a real plant-scoped role (2026-08-12): that operator saw only the doors their role grants and only their own record groups, with every figure matching the count predicted from the role's record groups before the test was run, and all 14 permission gates behaving correctly.
This is not claimed system-wide and not claimed complete. A role built on the Administrator preset can still have its record-group restriction discarded; that fix is merged on the platform mainline but not on the engagement release branch, and four endpoints are not yet covered by the scoping.
Alarms
The console prioritises alarms with a deterministic, per-tenant rules table held in the customer's own database — priority and display text are configured by the customer, not inferred by a model, so the same alarm can be routed differently at different sites. There is no AI component in this pipeline, and we would rather say so than imply one.
Classified alarms fan out to every matching subscription across five channel types — Everbridge, Microsoft Teams, Slack, an SMS gateway and generic HTTP — with per-subscription filtering by alarm type and priority, retry with exponential backoff, per-attempt dispatch history, and an operator test-fire button. The dispatch history writes one row per attempt rather than per alarm, so a channel that failed twice and succeeded on the third try says exactly that.
The Everbridge channel is built pending live-tenant certification: tenant credentials and payload validation are still outstanding, so it is not yet a live integration.
The audit trail
Every door-release decision — granted or refused — writes a row to the release audit table, capturing the door, cardholder ID, operator, timestamp, outcome, and, for a refusal, the reason it was blocked: badge state hold, no access rights, missing override acknowledgement, operator self-release, or controller rejection. Releases are recorded with the organization's own event codes.
The release audit record identifies the cardholder by numeric ID; it does not store a card or badge number.
Granted releases are additionally dual-written to the legacy audit tables in a single transaction, so the legacy application's activity views stay current and both consoles agree through cutover. Refusals are recorded in the release audit table.
Writing the custom event into Security Expert's own event log, the way the legacy web client did, is a known follow-up and is not shipping today.
How it deploys
Releases are the only deployment artifact. Knight Watch publishes a versioned, checksummed release package; the customer's own IT deploys it to Windows/IIS hosts they control (a container image is also available). Customer-owned production configuration is never shipped in, or overwritten by, a release, and no Knight Watch access to customer hosts is required to deploy.
the operator console is designed to coexist with the legacy web client through cutover rather than replace it in one move. Both applications read and write the same legacy audit tables in place — the operator console dual-writes the event log and transaction log in a single transaction so the legacy application's activity views stay current — so no data is migrated and the legacy client remains available as a fallback for the duration of the transition. Each release deployment also creates a timestamped backup of the previous version, with a documented rollback procedure to return to it.
Support
Business-hours support is standard, with an optional Premium tier adding 24x7 response for critical (P1/P2) incidents. Final coverage, response targets and escalation are set by the executed support addendum — and by the same team that installs and services the access control systems underneath the software.
No uptime percentage and no response-time target is published on this page. Those belong to a countersigned addendum, not to a brief.
What is not built today
Named here rather than left to be discovered: the badge photo processing pipeline, badge facility/area access audits, blacklists, and console offline local-table failover are roadmap only, with no code today. Badge Requests is hidden from the sidebar for the current engagement milestone — the route stays registered so direct URLs still work — and one of its seventeen scoped items is done.
Visitor mobile credentials via HID Origo (the HID Mobile Access API) are built into Security Expert Plus, delivered today on a single customer engagement's build, visitor-only — issued at check-in, revoked at check-out — and disabled by default pending production tenant configuration. Registering the issued card number in Security Expert for door access is a separate step, so the credential alone will not grant at a door until a matching cardholder record exists there.
Security Expert Plus is pre-release. No production go-live is evidenced as of 31 August 2026, and formal customer acceptance testing has not yet taken place. The Operator console is built and code-complete with automated test coverage; every other capability on this page carries its own status next to it.
The record-group verification quoted above is dated 2026-08-12, was run against a live production estate on a single enterprise engagement, and is not claimed system-wide. A verification against a production estate is not the same thing as the product running in production. The PingFederate single sign-on round-trip was completed in a non-production environment in June 2026; production verification, cutover and group-to-role mapping are pending.
Nothing on this page or in the deck is marked as running in production, because nothing is. Support coverage is set by the executed support addendum, not by this page. A technical walkthrough of the permission model with our engineering team is available on request.